The present invention relates generally to test vector definition systems, and more particularly to the use of a vector template concept in the user interface of an integrated circuit tester. This invention can also be used with logic simulators, where the same sort of data management problems exist.
An integrated circuit (IC) tester allows one to apply a sequence of signals to a device under test (DUT) and monitor its response by comparing that response to expected results. For each tester cycle, the signals to be applied to the input pins and the signals which are expected at the output pins are described by a "vector" of test data. A test is comprised of a sequence of such test vectors. The results of a completed test usually include some sort of listing of the discrepancies between actual and expected data.
To operate a tester, the user must physically connect the channels of the tester to the pins of the device. The first time that a particular device is tested, a lot of work goes into assigning and connecting the tester channels to the device pins. After the first time, the physical connection and channel assignment part of the job is much easier, especially if the tester will store all the decisions made the first time.
In addition to physically connecting the tester channels to the pins of the device, a user typically wishes to logically group the channels and label the channels and groups of channels with logical names. After the channels have been logically organized and named, one of the most difficult parts of the process of setting up the tester is to make all of the decisions about channel functions and masking, and clock timing.
The collective effect of the choices made by the user is to program the tester with a series of vectors to be executed in a specified sequence. The information associated with one vector of data includes, either explicitly or implicitly, at least the following:
Pin direction -- Is this channel going to be used as an input or an output during this cycle of tester operation?
Data content -- Is this channel expected to produce (or receive) a "1" or a "0" during this tester cycle?
Mask -- Do we want to ignore the data content of this channel during this cycle?
Voltage levels -- What voltages should be used to represent a high data value and a low data value?
Timing information -- When does the signal start and stop relative to the tester clock? How wide is the signal?
Format information -- How is the timing information used to format or `modulate` the signal at the tester pin? (In terms of the overall timing and the logic level that the signal returns to between active signals.)
For a tester which is capable of storing and generating as many as 65,000 vectors, each having a width of up to 256 channels, correctly entering all of this data into the tester is a very formidable task. Moreover, in more sophisticated testers, the operation of the tester may depend on feedback from the device under test, i.e., conditional branching or looping may be controlled by the occurrence or non-occurrence of DUT outputs.
As it becomes impractical to generate such a large number of vectors by hand, other methods for generating them are becoming more important. They may be generated algorithmically, by nesting, looping, and branching control through the use of some sort of programming language, so that a relatively few commands can describe a far larger number of vectors. Moreover, much of the data for inputs and outputs may be derived from simulations of the device on some other piece of equipment and downloaded to the tester for verification of actual performance relative to the predictions of the simulator. Such automated or semi-automated test vector generation is becoming increasingly important as the complexity of devices increases and testers are developed with very deep memories to accommodate the increased complexity.
In the testers of the prior art, a user controls the operation of the tester in one of two ways: either by making selections in a series of menus, or by programming the tester directly using a specialized programming language. The ASIX-1 Tester from ASIX Systems Corporation is an example of a tester that has a menu-driven user interface, while the Sentry Series from Fairchild is an example of a tester controlled with a specialized programming language.
In systems that use a programming language for direct user control of the system, such as the Sentry Series ATE from Fairchild Corporation, which uses a language (FACTOR, by TSSI Corp.) which is specialized for tester control, the user must first learn the language and then keep track of a large amount of data and his own prior decisions while programming the hardware registers of the tester. In such a system, a typical command might look like this: ##STR1## each of which sets the first 40 bits of a register (the F register) to a repeating binary value. Note that this command only establishes the state of 40 bits of data for one register controlling one of the numerous parameters that must be established for each tester cycle (vector).
The task of controlling each channel of a powerful tester by direct programmatic control over each bit of each register for every function one vector at a time is an extremely complicated task. It requires the user to be very familiar with the hardware of the tester, as well the programming language involved.
In the menu-driven user interfaces of the prior art, such as the ASIX-1 Tester from ASIX Systems Corporation, the Pin Definition menu allows the user to choose functions, formats, and a timing generator for each pin, but these definitions cannot be altered during execution of a particular test.
What is desired is a way to have control over a maximum number of functions for each channel on a channel-by-channel, vector-by-vector basis, with an easy to use human interface that provides visual feedback, does not require the user to learn a programming language, and makes the task of test vector definition readily manageable.